clipka wrote:
> Saul Luizaga schrieb:
> (*groans*)

Way to go to start a discussion...

> Sorry, but you violated the "suggetions to use GPU to speed up POV-Ray 
> may (and invariably will) be posted in intervals of 3 months" rule... we 
> just had this discussion about CUDA.
> 
> OpenCL can't change the basic hardware architecture of a GPU; all it 
> does is provide a layer on top (= added overhead!) to faciliate porting 
> existing programs to GPUs - still those programs must be suited to the 
> GPU architecture in order for the added processing power to outweigh the 
> surplus inter-xPU communication overhead, let alone give any speed benefit.

I think you are wrong: "OpenCL (Open Computing Language) greatly 
improves speed and responsiveness for a wide spectrum of applications in 
numerous market categories from gaming and entertainment to scientific 
and medical software."

 From here: 
http://www.khronos.org/news/press/releases/the_khronos_group_releases_opencl_1.0_specification/

Have you appreciated first hand that overhead making it inviable for 
POV-Ray?

> As soon as POV-Ray is fully capable of running a distributed render on a 
> network, it *might* be worth investigating whether the render back-end 
> could also be fully ported to GPUs, to just add some more "machines" to 
> the team. Until then, I don't think it makes much sense to think about 
> it (unless we'd want to develop a completely new render engine using a 
> totally different approach). And even then, question is whether the GPU 
> would be fast enough at the tasks at hand to pay off the effort of 
> getting the code to compile for the GPU.

"Tony Tamasi, senior vice president of technical marketing at NVIDIA 


powerful way to harness the enormous processing capabilities of our 
CUDA-based GPUs on multiple platforms." From the same link.

Some GPGPU provide 64-bit Floating Point computing wich is, I think, the 
major concern baout raytracing.At the seems some CUDA capable GPUs does 
and for sure some ATI's too:  ATI Stream Technology 
(http://www.amd.com/US/PRODUCTS/TECHNOLOGIES/STREAM-TECHNOLOGY/Pages/stream-technology.aspx).

> 
> OpenCL, however, will definitely *not* be an option, as it is a subset 
> of C (the 3.7 code is written in C++), and has severe limitations that 
> POV-Ray's architecture cannot comply with - most notably that recursions 
> are not allowed. POV-Ray absolutely positively needs recursions to 
> handle secondary rays, and also uses recursive calls for nested 
> definitions of textures pigments or CSG objects.

Granted, this new C standard (C99) is not fully supported in any C++ 
implementations; Intel C++ supports it for the most part but not fully. 
But I think a port to C++ probably is in the making since C++ is by
far more popular than C99 IMHO, so I think, since it has been released 
about 8 months ago, maybe there is a C++ ported OpenCL spec or maybe 
more by now. Many  computing intensive apps. would want this for themselves.

As you may know I participate in WCG (www.worldcommunitygrid.org) a 
scientific research worldwide computing grid for protein-based disease
research like AIDS, Cancer, Human Proteome Folding, etc. There is a 
GPU-based implementation of the Human Proteome Folding project and it 
makes great progress, so I know it works well.

OK, maybe is not as suitable for raytracing as it is for protein folding 
research, maybe the explanation why not is in the discussion about CUDA 
is where the answer is, but maybe is worth it because it has 64-bit 
Floating Point computing, which IIRC is the one and only big obstacle to 
avoid GPU-aided raytracing.

Or what I'm missing? don't want any details, only the highlights if you 
care to answer.

> 
>> PS: I think it should be a 'Suggestions' newsgroup for this sort of 
>> things.
> 
> povray.pov4.discussion.general might be an appropriate spot.

thanks, I think I'll try povray.programming.

Post a reply to this message